Technical Field
This application relates generally to distributed data processing systems and to the delivery of content to users over computer networks.
Brief Description of the Related Art
Distributed computer systems are known in the art. One such distributed computer system is a “content delivery network” or “CDN” that is operated and managed by a service provider. The service provider typically provides the content delivery service on behalf of third parties. A “distributed system” of this type typically refers to a collection of autonomous computers linked by a network or networks, together with the software, systems, protocols and techniques designed to facilitate various services, such as content delivery or the support of outsourced site infrastructure. This infrastructure is shared by multiple tenants, the content providers. The infrastructure is generally used for the storage, caching, or transmission of content—such as web pages, streaming media and applications—on behalf of such content providers or other tenants. The platform may also provide ancillary technologies used therewith including, without limitation, DNS query handling, provisioning, data monitoring and reporting, content targeting, personalization, and business intelligence.
In a known system such as that shown in FIG. 1, a distributed computer system 100 is configured as a content delivery network (CDN) and has a set of servers 102 distributed around the Internet. Typically, most of the servers are located near the edge of the Internet, i.e., at or adjacent end user access networks. A network operations command center (NOCC) 104 may be used to administer and manage operations of the various machines in the system. Third party sites affiliated with content providers, such as web site 106, offload delivery of content (e.g., HTML or other markup language files, embedded page objects, streaming media, software downloads, and the like) to the distributed computer system 100 and, in particular, to the CDN servers (which are sometimes referred to as content servers, or sometimes as “edge” servers in light of the possibility that they are near an “edge” of the Internet). Such CDN servers 102 may be grouped together into a point of presence (POP) 107 at a particular geographic location.
The CDN servers are typically located at nodes that are publicly-routable on the Internet, in end-user access networks, peering points, within or adjacent nodes that are located in mobile networks, in or adjacent enterprise-based private networks, or in any combination thereof.
Typically, content providers offload their content delivery by aliasing (e.g., by a DNS CNAME) given content provider domains or sub-domains to domains that are managed by the service provider's authoritative domain name service. The server provider's domain name service directs end user client machines 122 that desire content to the distributed computer system (or more particularly, to one of the CDN servers in the platform) to obtain the content more reliably and efficiently. The CDN servers respond to the client requests, for example by fetching requested content from a local cache, from another CDN server, from an origin server 106 associated with the content provider, or other source, and sending it to the requesting client.
For cacheable content, CDN servers typically employ a caching model that relies on setting a time-to-live (TTL) for each cacheable object. After it is fetched, the object may be stored locally at a given CDN server until the TTL expires, at which time is typically re-validated or refreshed from the origin server 106. For non-cacheable objects (sometimes referred to as ‘dynamic’ content), the CDN server typically returns to the origin server 106 when the object is requested by a client. The CDN may operate a server cache hierarchy to provide intermediate caching of customer content in various CDN servers that are between the CDN server handling a client request and the origin server 106; one such cache hierarchy subsystem is described in U.S. Pat. No. 7,376,716, the disclosure of which is incorporated herein by reference.
Although not shown in detail in FIG. 1, the distributed computer system may also include other infrastructure, such as a distributed data collection system 108 that collects usage and other data from the CDN servers, aggregates that data across a region or set of regions, and passes that data to other back-end systems 110, 112, 114 and 116 to facilitate monitoring, logging, alerts, billing, management and other operational and administrative functions. Distributed network agents 118 monitor the network as well as the server loads and provide network, traffic and load data to a DNS query handling mechanism 115. A distributed data transport mechanism 120 may be used to distribute control information (e.g., metadata to manage content, to facilitate load balancing, and the like) to the CDN servers. The CDN may include a network storage subsystem (sometimes referred to herein as “NetStorage”) which may be located in a network datacenter accessible to the CDN servers and which may act as a source of content, such as described in U.S. Pat. No. 7,472,178, the disclosure of which is incorporated herein by reference.
As illustrated in FIG. 2, a given machine 200 in the CDN comprises commodity hardware (e.g., a microprocessor) 202 running an operating system kernel (such as Linux® or variant) 204 that supports one or more applications 206a-n. To facilitate content delivery services, for example, given machines typically run a set of applications, such as an HTTP proxy 207, a name service 208, a local monitoring process 210, a distributed data collection process 212, and the like. The HTTP proxy 207 (sometimes referred to herein as a global host or “ghost”) typically includes a manager process for managing a cache and delivery of content from the machine. For streaming media, the machine may include one or more media servers, such as a Windows® Media Server (WMS) or Flash server, as required by the supported media formats.
A given CDN server 102 seen in FIG. 1 may be configured to provide one or more extended content delivery features, preferably on a domain-specific, content-provider-specific basis, preferably using configuration files that are distributed to the CDN servers using a configuration system. A given configuration file preferably is XML-based and includes a set of content handling rules and directives that facilitate one or more advanced content handling features. The configuration file may be delivered to the CDN server via the data transport mechanism. U.S. Pat. No. 7,240,100, the contents of which are hereby incorporated by reference, describe a useful infrastructure for delivering and managing CDN server content control information, and this and other control information (sometimes referred to as “metadata”) can be provisioned by the CDN service provider itself, or (via an extranet or the like) the content provider customer who operates the origin server. U.S. Pat. No. 7,111,057, incorporated herein by reference, describes an architecture for purging content from the CDN. More information about a CDN platform can be found in U.S. Pat. Nos. 6,108,703 and 7,596,619, the teachings of which are hereby incorporated by reference in their entirety.
In a typical operation, a content provider identifies a content provider domain or sub-domain that it desires to have served by the CDN. When a DNS query to the content provider domain or sub-domain is received at the content provider's domain name servers, those servers respond by returning the CDN hostname (e.g., via a canonical name, or CNAME, or other aliasing technique). That network hostname points to the CDN, and that hostname is then resolved through the CDN name service. To that end, the CDN name service returns one or more IP addresses. The requesting client application (e.g., browser) then makes a content request (e.g., via HTTP or HTTPS) to a CDN server machine associated with the IP address. The request includes a host header that includes the original content provider domain or sub-domain. Upon receipt of the request with the host header, the CDN server checks its configuration file to determine whether the content domain or sub-domain requested is actually being handled by the CDN. If so, the CDN server applies its content handling rules and directives for that domain or sub-domain as specified in the configuration. These content handling rules and directives may be located within an XML-based “metadata” configuration file, as mentioned previously.
The CDN platform may be considered an overlay across the Internet on which communication efficiency can be improved. Improved communications techniques on the overlay can help when a CDN server needs to obtain content from origin server 106, or otherwise when accelerating non-cacheable content for a content provider customer. Communications between CDN servers and/or across the overlay may be enhanced or improved using improved route selection, protocol optimizations including TCP enhancements, persistent connection reuse and pooling, content & header compression and de-duplication, and other techniques such as those described in U.S. Pat. Nos. 6,820,133, 7,274,658, 7,607,062, and 7,660,296, among others, the disclosures of which are incorporated herein by reference.
As an overlay offering communication enhancements and acceleration, the CDN server resources may be used to facilitate wide area network (WAN) acceleration services between enterprise data centers and/or between branch-headquarter offices (which may be privately managed), as well as to/from third party software-as-a-service (SaaS) providers used by the enterprise users.
In this vein CDN customers may subscribe to a “behind the firewall” managed service product to accelerate Intranet web applications that are hosted behind the customer's enterprise firewall, as well as to accelerate web applications that bridge between their users behind the firewall to an application hosted in the Internet cloud (e.g., from a SaaS provider).
To accomplish these two use cases, CDN software may execute on machines (potentially in virtual machines running on customer hardware) hosted in one or more customer data centers, and on machines hosted in remote “branch offices.” The CDN software executing in the customer data center typically provides service configuration, service management, service reporting, remote management access, customer SSL/TLS certificate management, as well as other functions for configured web applications. The software executing in the branch offices provides last mile web acceleration for users located there. The CDN itself typically provides CDN hardware hosted in CDN data centers to provide a gateway between the nodes running behind the customer firewall and the CDN service provider's other infrastructure (e.g., network and operations facilities). This type of managed solution provides an enterprise with the opportunity to take advantage of CDN technologies with respect to their company's intranet, providing a wide-area-network optimization solution. This kind of solution extends acceleration for the enterprise to applications served anywhere on the Internet. By bridging an enterprise's CDN-based private overlay network with the existing CDN public internet overlay network, an end user at a remote branch office obtains an accelerated application end-to-end. FIG. 3 illustrates a general architecture for a WAN optimized, “behind-the-firewall” service offering such as that described above. Information about a behind the firewall service offering can be found in teachings of U.S. Pat. No. 7,600,025, the teachings of which are hereby incorporated by reference.
For live streaming delivery, the CDN may include a live delivery subsystem, such as described in U.S. Pat. No. 7,296,082, and U.S. Publication Nos. 2011/0173345 and 2012/0265853, the disclosures of which are incorporated herein by reference.
Turning to the topic of network protocols, the Hypertext Transfer Protocol (HTTP) is a well-known application layer protocol in the art. It is often used for transporting HTML documents that define the presentation of web pages, as well as embedded resources associated with such pages. The HTTP 1.0 and 1.1 standards came about in the 1990s. Recently, HTTP 2.0, a major revision to HTTP, has been approved for standards track consideration by the IETF (RFC 7540). The HTTP 2.0 proposed standard has been in development for some time (see, e.g., HTTP version 2, working draft, draft-ietf-httpbis-http2-16, Nov. 29, 2014). According to that working draft and RFC 7540, HTTP 2.0 enables efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent messages on the same connection. It also introduces unsolicited push of representations from servers to clients. HTTP 2.0 is based on an earlier protocol, SPDY, which also offered an unsolicited push feature.
Server push features present the opportunity for increased efficiencies, but must be used wisely. For example, it is known in the art to predict resources that a client may request, given an initial request (e.g., for a base HTML page). A variety of prediction algorithms are known the art, including the prefetching approaches described in U.S. Pat. No. 8,447,837, US Patent Publication No. 2014/0379840, US Patent Publication No. 2015/0089352, and US Patent Publication No. 2015/0120821, the contents of all of which are hereby incorporated by reference.
It is also known in the art to use predictions to push resources to a client using the push mechanism contemplated in SPDY and HTTP 2.0. Pushing content to the client can result in wasted bandwidth if the prediction is wrong, or if the client already has the resource in a client-side cache. To address this issue, it has been proposed in the prior art that the hint mechanism of SPDY could be used to search the browser's cache to ensure that already-cached resources are not re-fetched by the proxy. (See, e.g., Nicholas Armstrong, Just in Time Push Prefetching: Accelerating the Mobile Web, University of Waterloo Master's Thesis, 2011.) Further, Uzonov (Andrey Uzonov, Speeding Up Tor With SPDY, Master's Thesis, Munich Technical University, 2013) proposes collecting statistical data about resource requests for a page, and for subsequent page requests, pushing resources when his proposed algorithm(s) are confident enough that they would be requested in the page load. The algorithms described by Uzonov take into account the frequency with which a resource is requested overall, or for a particular page load, as well as the number of times that a resource has been seen after the first page load in a session, or in prior page loads. Several algorithms are proposed. Uzonov investigates the use of a cost function for pushing resources that accounts for hits and mistakes. Uzonov also proposes, among other things, considering the device type or browser type (user-agent) in determining whether to push assets, setting a maximum asset size for push, and keeping track of the assets that have provided to the client previously (at the server or at the client) to avoid re-sending them.
While the foregoing approaches are valuable, there remains a need for improved approaches that intelligently determine those objects a server should push to a client, and those objects a server should not push, when leveraging a push mechanism such as that provided HTTP 2.0. The teachings hereof are not necessarily limited to HTTP 2.0, but apply to any mechanism for pushing web page components from a server to a client.
The teachings hereof can be used to improve the efficiency of web page loading and of network usage, among other things.